<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel, branch linux-4.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.19.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.19.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-12-05T09:59:42Z</updated>
<entry>
<title>Linux 4.19.325</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2024-12-05T09:59:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a67e7cdde7cc7984ae24c3c81a70dc1aa34424b1'/>
<id>urn:sha1:a67e7cdde7cc7984ae24c3c81a70dc1aa34424b1</id>
<content type='text'>
Link: https://lore.kernel.org/r/20241203141923.524658091@linuxfoundation.org
Tested-by: Harshit Mogalapalli &lt;harshit.m.mogalapalli@oracle.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sh: intc: Fix use-after-free bug in register_intc_controller()</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2024-10-23T08:41:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3c7c806b3eafd94ae0f77305a174d63b69ec187c'/>
<id>urn:sha1:3c7c806b3eafd94ae0f77305a174d63b69ec187c</id>
<content type='text'>
[ Upstream commit 63e72e551942642c48456a4134975136cdcb9b3c ]

In the error handling for this function, d is freed without ever
removing it from intc_list which would lead to a use after free.
To fix this, let's only add it to the list after everything has
succeeded.

Fixes: 2dcec7a988a1 ("sh: intc: set_irq_wake() support")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Reviewed-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt;
Signed-off-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>modpost: remove incorrect code in do_eisa_entry()</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2024-11-19T23:56:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=94a6159f610cd97cccc8735e4ddc094f16438a18'/>
<id>urn:sha1:94a6159f610cd97cccc8735e4ddc094f16438a18</id>
<content type='text'>
[ Upstream commit 0c3e091319e4748cb36ac9a50848903dc6f54054 ]

This function contains multiple bugs after the following commits:

 - ac551828993e ("modpost: i2c aliases need no trailing wildcard")
 - 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling")

Commit ac551828993e inserted the following code to do_eisa_entry():

    else
            strcat(alias, "*");

This is incorrect because 'alias' is uninitialized. If it is not
NULL-terminated, strcat() could cause a buffer overrun.

Even if 'alias' happens to be zero-filled, it would output:

    MODULE_ALIAS("*");

This would match anything. As a result, the module could be loaded by
any unrelated uevent from an unrelated subsystem.

Commit ac551828993e introduced another bug.            

Prior to that commit, the conditional check was:

    if (eisa-&gt;sig[0])

This checked if the first character of eisa_device_id::sig was not '\0'.

However, commit ac551828993e changed it as follows:

    if (sig[0])

sig[0] is NOT the first character of the eisa_device_id::sig. The
type of 'sig' is 'char (*)[8]', meaning that the type of 'sig[0]' is
'char [8]' instead of 'char'. 'sig[0]' and 'symval' refer to the same
address, which never becomes NULL.

The correct conversion would have been:

    if ((*sig)[0])

However, this if-conditional was meaningless because the earlier change
in commit ac551828993e was incorrect.

This commit removes the entire incorrect code, which should never have
been executed.

Fixes: ac551828993e ("modpost: i2c aliases need no trailing wildcard")
Fixes: 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling")
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>9p/xen: fix release of IRQ</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Alex Zenla</name>
<email>alex@edera.dev</email>
</author>
<published>2024-11-21T22:51:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=692eb06703afc3e24d889d77e94a0e20229f6a4a'/>
<id>urn:sha1:692eb06703afc3e24d889d77e94a0e20229f6a4a</id>
<content type='text'>
[ Upstream commit e43c608f40c065b30964f0a806348062991b802d ]

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend")
Signed-off-by: Alex Zenla &lt;alex@edera.dev&gt;
Signed-off-by: Alexander Merritt &lt;alexander@edera.dev&gt;
Signed-off-by: Ariadne Conill &lt;ariadne@ariadne.space&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Message-ID: &lt;20241121225100.5736-1-alexander@edera.dev&gt;
[Dominique: remove confusing variable reset to 0]
Signed-off-by: Dominique Martinet &lt;asmadeus@codewreck.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>9p/xen: fix init sequence</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Alex Zenla</name>
<email>alex@edera.dev</email>
</author>
<published>2024-11-19T21:16:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c9a1f766ab1c154c4ef9f2211285f5021c3bfd73'/>
<id>urn:sha1:c9a1f766ab1c154c4ef9f2211285f5021c3bfd73</id>
<content type='text'>
[ Upstream commit 7ef3ae82a6ebbf4750967d1ce43bcdb7e44ff74b ]

Large amount of mount hangs observed during hotplugging of 9pfs devices. The
9pfs Xen driver attempts to initialize itself more than once, causing the
frontend and backend to disagree: the backend listens on a channel that the
frontend does not send on, resulting in stalled processing.

Only allow initialization of 9p frontend once.

Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence")
Signed-off-by: Alex Zenla &lt;alex@edera.dev&gt;
Signed-off-by: Alexander Merritt &lt;alexander@edera.dev&gt;
Signed-off-by: Ariadne Conill &lt;ariadne@ariadne.space&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Message-ID: &lt;20241119211633.38321-1-alexander@edera.dev&gt;
Signed-off-by: Dominique Martinet &lt;asmadeus@codewreck.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>block: return unsigned int from bdev_io_min</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-11-19T07:26:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3947b10ee8cdb1f9cac96e4cc294d641c7e67743'/>
<id>urn:sha1:3947b10ee8cdb1f9cac96e4cc294d641c7e67743</id>
<content type='text'>
[ Upstream commit 46fd48ab3ea3eb3bb215684bd66ea3d260b091a9 ]

The underlying limit is defined as an unsigned int, so return that from
bdev_io_min as well.

Fixes: ac481c20ef8f ("block: Topology ioctls")
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reviewed-by: John Garry &lt;john.g.garry@oracle.com&gt;
Link: https://lore.kernel.org/r/20241119072602.1059488-1-hch@lst.de
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>jffs2: fix use of uninitialized variable</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Qingfang Deng</name>
<email>qingfang.deng@siflower.com.cn</email>
</author>
<published>2024-07-01T04:52:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b4cf0e755156c277755bf572567c19f5e9a1c61d'/>
<id>urn:sha1:b4cf0e755156c277755bf572567c19f5e9a1c61d</id>
<content type='text'>
[ Upstream commit 3ba44ee966bc3c41dd8a944f963466c8fcc60dc8 ]

When building the kernel with -Wmaybe-uninitialized, the compiler
reports this warning:

In function 'jffs2_mark_erased_block',
    inlined from 'jffs2_erase_pending_blocks' at fs/jffs2/erase.c:116:4:
fs/jffs2/erase.c:474:9: warning: 'bad_offset' may be used uninitialized [-Wmaybe-uninitialized]
  474 |         jffs2_erase_failed(c, jeb, bad_offset);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/jffs2/erase.c: In function 'jffs2_erase_pending_blocks':
fs/jffs2/erase.c:402:18: note: 'bad_offset' was declared here
  402 |         uint32_t bad_offset;
      |                  ^~~~~~~~~~

When mtd-&gt;point() is used, jffs2_erase_pending_blocks can return -EIO
without initializing bad_offset, which is later used at the filebad
label in jffs2_mark_erased_block.
Fix it by initializing this variable.

Fixes: 8a0f572397ca ("[JFFS2] Return values of jffs2_block_check_erase error paths")
Signed-off-by: Qingfang Deng &lt;qingfang.deng@siflower.com.cn&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ubi: fastmap: Fix duplicate slab cache names while attaching</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-10-11T04:50:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ef52b7191ac41e68b1bf070d00c5b04ed16e4920'/>
<id>urn:sha1:ef52b7191ac41e68b1bf070d00c5b04ed16e4920</id>
<content type='text'>
[ Upstream commit bcddf52b7a17adcebc768d26f4e27cf79adb424c ]

Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when
DEBUG_VM=y"), the duplicate slab cache names can be detected and a
kernel WARNING is thrown out.
In UBI fast attaching process, alloc_ai() could be invoked twice
with the same slab cache name 'ubi_aeb_slab_cache', which will trigger
following warning messages:
 kmem_cache of name 'ubi_aeb_slab_cache' already exists
 WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107
          __kmem_cache_create_args+0x100/0x5f0
 Modules linked in: ubi(+) nandsim [last unloaded: nandsim]
 CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2
 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0
 Call Trace:
   __kmem_cache_create_args+0x100/0x5f0
   alloc_ai+0x295/0x3f0 [ubi]
   ubi_attach+0x3c3/0xcc0 [ubi]
   ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]
   ubi_init+0x3fb/0x800 [ubi]
   do_init_module+0x265/0x7d0
   __x64_sys_finit_module+0x7a/0xc0

The problem could be easily reproduced by loading UBI device by fastmap
with CONFIG_DEBUG_VM=y.
Fix it by using different slab names for alloc_ai() callers.

Fixes: d2158f69a7d4 ("UBI: Remove alloc_ai() slab name from parameter list")
Fixes: fdf10ed710c0 ("ubi: Rework Fastmap attach base code")
Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ubifs: Correct the total block count by deducting journal reservation</title>
<updated>2024-12-05T09:59:42Z</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-09-05T01:09:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4be5be8e4dcb34c70ec4a50e5141354380e552dc'/>
<id>urn:sha1:4be5be8e4dcb34c70ec4a50e5141354380e552dc</id>
<content type='text'>
[ Upstream commit 84a2bee9c49769310efa19601157ef50a1df1267 ]

Since commit e874dcde1cbf ("ubifs: Reserve one leb for each journal
head while doing budget"), available space is calulated by deducting
reservation for all journal heads. However, the total block count (
which is only used by statfs) is not updated yet, which will cause
the wrong displaying for used space(total - available).
Fix it by deducting reservation for all journal heads from total
block count.

Fixes: e874dcde1cbf ("ubifs: Reserve one leb for each journal head while doing budget")
Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rtc: check if __rtc_read_time was successful in rtc_timer_do_work()</title>
<updated>2024-12-05T09:59:41Z</updated>
<author>
<name>Yongliang Gao</name>
<email>leonylgao@tencent.com</email>
</author>
<published>2024-10-11T04:31:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f'/>
<id>urn:sha1:39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f</id>
<content type='text'>
[ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ]

If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtc_tm_to_ktime later, the result may be a very large value
(possibly KTIME_MAX). If there are periodic timers in rtc-&gt;timerqueue,
they will continually expire, may causing kernel softlockup.

Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
Signed-off-by: Yongliang Gao &lt;leonylgao@tencent.com&gt;
Acked-by: Jingqun Li &lt;jingqunli@tencent.com&gt;
Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
