<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/char/hpet.c, branch linux-5.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-07-18T11:05:49Z</updated>
<entry>
<title>hpet: Support 32-bit userspace</title>
<updated>2024-07-18T11:05:49Z</updated>
<author>
<name>He Zhe</name>
</author>
<published>2024-06-06T12:39:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bdb9c58e8048d4d81e7b5bcfd49bd88bf0c8be67'/>
<id>urn:sha1:bdb9c58e8048d4d81e7b5bcfd49bd88bf0c8be67</id>
<content type='text'>
commit 4e60131d0d36af65ab9c9144f4f163fe97ae36e8 upstream.

hpet_compat_ioctl and read file operations failed to handle parameters from
32-bit userspace and thus samples/timers/hpet_example.c fails as below.

root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
-hpet: executing poll
hpet_poll: HPET_IRQFREQ failed

This patch fixes cmd and arg handling in hpet_compat_ioctl and adds compat
handling for 32-bit userspace in hpet_read.

hpet_example now shows that it works for both 64-bit and 32-bit.

root@intel-x86-64:~# ./hpet_example-32.out poll /dev/hpet 1 2
-hpet: executing poll
hpet_poll: info.hi_flags 0x0
hpet_poll: expired time = 0xf4298
hpet_poll: revents = 0x1
hpet_poll: data 0x1
hpet_poll: expired time = 0xf4235
hpet_poll: revents = 0x1
hpet_poll: data 0x1
root@intel-x86-64:~# ./hpet_example-64.out poll /dev/hpet 1 2
-hpet: executing poll
hpet_poll: info.hi_flags 0x0
hpet_poll: expired time = 0xf42a1
hpet_poll: revents = 0x1
hpet_poll: data 0x1
hpet_poll: expired time = 0xf4232
hpet_poll: revents = 0x1
hpet_poll: data 0x1

Cc: stable@vger.kernel.org
Signed-off-by: He Zhe &lt;zhe.he@windriver.com&gt;
Fixes: 54066a57c584 ("hpet: kill BKL, add compat_ioctl")
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/20240606123908.738733-1-zhe.he@windriver.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>char: hpet: add checks after calling ioremap</title>
<updated>2021-06-03T07:00:41Z</updated>
<author>
<name>Tom Seewald</name>
</author>
<published>2021-05-03T11:56:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c8972b14044a81abcb29526e89140cd81364febb'/>
<id>urn:sha1:c8972b14044a81abcb29526e89140cd81364febb</id>
<content type='text'>
[ Upstream commit b11701c933112d49b808dee01cb7ff854ba6a77a ]

The function hpet_resources() calls ioremap() two times, but in both
cases it does not check if ioremap() returned a null pointer. Fix this
by adding null pointer checks and returning an appropriate error.

Signed-off-by: Tom Seewald &lt;tseewald@gmail.com&gt;
Link: https://lore.kernel.org/r/20210503115736.2104747-30-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "char: hpet: fix a missing check of ioremap"</title>
<updated>2021-06-03T07:00:41Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
</author>
<published>2021-05-03T11:56:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0f4e71f3d3393c56df8e0690db84f0c395fc2d31'/>
<id>urn:sha1:0f4e71f3d3393c56df8e0690db84f0c395fc2d31</id>
<content type='text'>
[ Upstream commit 566f53238da74801b48e985788e5f7c9159e5940 ]

This reverts commit 13bd14a41ce3105d5b1f3cd8b4d1e249d17b6d9b.

Because of recent interactions with developers from @umn.edu, all
commits from them have been recently re-reviewed to ensure if they were
correct or not.

Upon review, this commit was found to be incorrect for the reasons
below, so it must be reverted.  It will be fixed up "correctly" in a
later kernel change.

While this is technically correct, it is only fixing ONE of these errors
in this function, so the patch is not fully correct.  I'll leave this
revert and provide a fix for this later that resolves this same
"problem" everywhere in this function.

Cc: Kangjie Lu &lt;kjlu@umn.edu&gt;
Link: https://lore.kernel.org/r/20210503115736.2104747-29-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>char: hpet: Fix out-of-bounds read bug</title>
<updated>2020-01-30T05:58:33Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2020-01-29T02:26:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=98c49f1746ac44ccc164e914b9a44183fad09f51'/>
<id>urn:sha1:98c49f1746ac44ccc164e914b9a44183fad09f51</id>
<content type='text'>
Currently, there is an out-of-bounds read on array hpetp-&gt;hp_dev
in the following for loop:

870         for (i = 0; i &lt; hdp-&gt;hd_nirqs; i++)
871                 hpetp-&gt;hp_dev[i].hd_hdwirq = hdp-&gt;hd_irq[i];

This is due to the recent change from one-element array to
flexible-array member in struct hpets:

104 struct hpets {
	...
113         struct hpet_dev hp_dev[];
114 };

This change affected the total size of the dynamic memory
allocation, decreasing it by one time the size of struct hpet_dev.

Fix this by adjusting the allocation size when calling
struct_size().

Fixes: 987f028b8637c ("char: hpet: Use flexible-array member")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Acked-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Link: https://lore.kernel.org/r/20200129022613.GA24281@embeddedor.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>char: hpet: Use flexible-array member</title>
<updated>2020-01-23T18:54:26Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2020-01-20T23:53:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=987f028b8637cfa7658aa456ae73f8f21a7a7f6f'/>
<id>urn:sha1:987f028b8637cfa7658aa456ae73f8f21a7a7f6f</id>
<content type='text'>
Old code in the kernel uses 1-byte and 0-byte arrays to indicate the
presence of a "variable length array":

struct something {
    int length;
    u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance-&gt;length = size;
memcpy(instance-&gt;data, source, size);

There is also 0-byte arrays. Both cases pose confusion for things like
sizeof(), CONFIG_FORTIFY_SOURCE, etc.[1] Instead, the preferred mechanism
to declare variable-length types such as the one above is a flexible array
member[2] which need to be the last member of a structure and empty-sized:

struct something {
        int stuff;
        u8 data[];
};

Also, by making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
unadvertenly introduced[3] to the codebase from now on.

[1] https://github.com/KSPP/linux/issues/21
[2] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Link: https://lore.kernel.org/r/20200120235326.GA29231@embeddedor.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hpet: Fix division by zero in hpet_time_div()</title>
<updated>2019-07-25T12:39:51Z</updated>
<author>
<name>Kefeng Wang</name>
</author>
<published>2019-07-11T13:27:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0c7d37f4d9b8446956e97b7c5e61173cdb7c8522'/>
<id>urn:sha1:0c7d37f4d9b8446956e97b7c5e61173cdb7c8522</id>
<content type='text'>
The base value in do_div() called by hpet_time_div() is truncated from
unsigned long to uint32_t, resulting in a divide-by-zero exception.

UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2
division by zero
CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561
 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20
 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0
Call Trace:
 [&lt;ffffffff81ad7561&gt;] __dump_stack lib/dump_stack.c:15 [inline]
 [&lt;ffffffff81ad7561&gt;] dump_stack+0xc1/0x120 lib/dump_stack.c:51
 [&lt;ffffffff81b8f25e&gt;] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166
 [&lt;ffffffff81b900cb&gt;] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262
 [&lt;ffffffff823560dd&gt;] hpet_time_div drivers/char/hpet.c:572 [inline]
 [&lt;ffffffff823560dd&gt;] hpet_ioctl_common drivers/char/hpet.c:663 [inline]
 [&lt;ffffffff823560dd&gt;] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577
 [&lt;ffffffff81e63d56&gt;] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676
 [&lt;ffffffff81711590&gt;] vfs_ioctl fs/ioctl.c:43 [inline]
 [&lt;ffffffff81711590&gt;] file_ioctl fs/ioctl.c:470 [inline]
 [&lt;ffffffff81711590&gt;] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605
 [&lt;ffffffff81711eb4&gt;] SYSC_ioctl fs/ioctl.c:622 [inline]
 [&lt;ffffffff81711eb4&gt;] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613
 [&lt;ffffffff82846003&gt;] tracesys_phase2+0x90/0x95

The main C reproducer autogenerated by syzkaller,

  syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
  memcpy((void*)0x20000100, "/dev/hpet\000", 10);
  syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
  syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000);

Fix it by using div64_ul().

Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
Signed-off-by: Zhang HongJun &lt;zhanghongjun2@huawei.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500</title>
<updated>2019-06-19T15:09:55Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2019-06-04T08:11:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d2912cb15bdda8ba4a5dd73396ad62641af2f520'/>
<id>urn:sha1:d2912cb15bdda8ba4a5dd73396ad62641af2f520</id>
<content type='text'>
Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Enrico Weigelt &lt;info@metux.net&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>char: hpet: fix a missing check of ioremap</title>
<updated>2019-03-27T17:15:51Z</updated>
<author>
<name>Kangjie Lu</name>
</author>
<published>2019-03-09T03:50:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=13bd14a41ce3105d5b1f3cd8b4d1e249d17b6d9b'/>
<id>urn:sha1:13bd14a41ce3105d5b1f3cd8b4d1e249d17b6d9b</id>
<content type='text'>
Check if ioremap fails, and if so, return AE_ERROR.

Signed-off-by: Kangjie Lu &lt;kjlu@umn.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hpet: Use struct_size() in kzalloc()</title>
<updated>2019-02-26T11:53:55Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2019-02-19T22:10:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=401c9bd10beef4b030eb9e34d16b5341dc6c683b'/>
<id>urn:sha1:401c9bd10beef4b030eb9e34d16b5341dc6c683b</id>
<content type='text'>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
    int stuff;
    struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable siz is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable</title>
<updated>2019-01-22T12:34:35Z</updated>
<author>
<name>Buland Singh</name>
</author>
<published>2018-12-20T12:05:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=24d48a61f2666630da130cc2ec2e526eacf229e3'/>
<id>urn:sha1:24d48a61f2666630da130cc2ec2e526eacf229e3</id>
<content type='text'>
Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for
user processes")' introduced a new kernel command line parameter hpet_mmap,
that is required to expose the memory map of the HPET registers to
user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
broken and never takes effect due to missing '=' character in the __setup()
code of hpet_mmap_enable.

Before this patch:

dmesg output with the kernel command line parameter hpet_mmap=1

[    0.204152] HPET mmap disabled

dmesg output with the kernel command line parameter hpet_mmap=0

[    0.204192] HPET mmap disabled

After this patch:

dmesg output with the kernel command line parameter hpet_mmap=1

[    0.203945] HPET mmap enabled

dmesg output with the kernel command line parameter hpet_mmap=0

[    0.204652] HPET mmap disabled

Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
Signed-off-by: Buland Singh &lt;bsingh@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
