In the Linux kernel, the following vulnerability has been resolved:
net: fix data-races around sk->skforwardalloc
Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---
Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()
In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0
The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: allocate vfstate during PF probes
In the previous implementation, vfstate is allocated memory only when VF is enabled. However, netdeviceops::ndosetvfmac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetcpfsetvfmac() will access vfstate, resulting in access to a null pointer. The simplified error log is as follows.
root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetcpfsetvfmac+0x3c/0x80 Message from sy [ 173.641973] lr : dosetlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetcpfsetvfmac+0x3c/0x80 [ 173.738847] rtnlnewlink+0x530/0x89c [ 173.742692] rtnlnewlink+0x50/0x7c [ 173.746189] rtnetlinkrcvmsg+0x128/0x390 [ 173.750298] netlinkrcvskb+0x60/0x130 [ 173.754145] rtnetlinkrcv+0x18/0x24 [ 173.757731] netlinkunicast+0x318/0x380 [ 173.761665] netlinksendmsg+0x17c/0x3c8
bpf: Fix overloading of MEMUNINIT's meaning
HID: core: zero-initialize the report buffer
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix 6 GHz scan construction
If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope.
Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix UAF on scosocktimeout
conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Consider the NULL character when validating the event length
strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.
This commit checks this condition and returns failure for it.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: check outstanding simultaneous SMB operations
If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbdworkcache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.
In the Linux kernel, the following vulnerability has been resolved:
sctp: properly validate chunk size in sctpsfootb()
A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot:
BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233
iio: light: veml6030: fix IIO device retrieval from embedded device
In the Linux kernel, the following vulnerability has been resolved:
x86/entry32: Clear CPU buffers after register restore in NMI return
CPU buffers are currently cleared after call to excnmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data.
Move CLEARCPUBUFFERS after RESTOREALLNMI.
In the Linux kernel, the following vulnerability has been resolved:
staging: iio: frequency: ad9832: fix division by zero in ad9832calcfreqreg()
In the ad9832writefrequency() function, clkgetrate() might return 0. This can lead to a division by zero when calling ad9832calcfreqreg(). The check if (fout > (clkgetrate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832writefrequency() function is called from ad9832write(), and fout is derived from a text buffer, which can contain any value.
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: ocelot: fix system hang on level based interrupts
The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts.
for (i = 0; i < info->stride; i++) { uregmapread(info->map, idreg + 4 i, ®); if (!reg) continue;
chainedirqenter(parentchip, desc);
However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt.
Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware.
The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chainedirqenter drivers/pinctrl
In the Linux kernel, the following vulnerability has been resolved:
net: systemport: fix potential memory leak in bcmsysportxmit()
The bcmsysportxmit() returns NETDEVTXOK without freeing skb in case of dmamapsingle() fails, add devkfreeskb() to fix it.
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential deadlock with newly created symlinks
Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock.
This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem().
This is not a problem for symlinks read from the backing device, because the GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held:
Fix this issue by dropping the GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOBs when building SMB2IOCTL request
When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2setnextcommand().
SMB2ioctlinit() allocates a small buffer (448 bytes) to hold the SMB2IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2setnextcommand() will end up writing off the end of @rqst->iov[0].iovbase as shown below:
mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link
BUG: KASAN: slab-out-of-bounds in smb2setnextcommand.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859
CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] printreport+0x156/0x4d9 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] ? virtaddrvalid+0x145/0x310 ? physaddr+0x46/0x90 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasanreport+0xda/0x110 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasancheckrange+0x10f/0x1f0 asanmemcpy+0x3c/0x60 smb2setnextcommand.cold+0x1d6/0x24c [cifs] smb2compoundop+0x238c/0x3840 [cifs] ? kasansavetrack+0x14/0x30 ? kasansavefreeinfo+0x3b/0x70 ? vfssymlink+0x1a1/0x2c0 ? dosymlinkat+0x108/0x1c0 ? pfxsmb2compoundop+0x10/0x10 [cifs] ? kmemcachefree+0x118/0x3e0 ? cifsgetwritablepath+0xeb/0x1a0 [cifs] smb2getreparseinode+0x423/0x540 [cifs] ? pfxsmb2getreparseinode+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? kmallocnoprof+0x37c/0x480 ? smb2createreparsesymlink+0x257/0x490 [cifs] ? smb2createreparsesymlink+0x38f/0x490 [cifs] smb2createreparsesymlink+0x38f/0x490 [cifs] ? pfxsmb2createreparsesymlink+0x10/0x10 [cifs] ? findheldlock+0x8a/0xa0 ? hlockclass+0x32/0xb0 ? buildpathfromdentryoptionalprefix+0x19d/0x2e0 [cifs] cifssymlink+0x24f/0x960 [cifs] ? pfxmakevfsuid+0x10/0x10 ? pfxcifssymlink+0x10/0x10 [cifs] ? makevfsgid+0x6b/0xc0 ? genericpermission+0x96/0x2d0 vfssymlink+0x1a1/0x2c0 dosymlinkat+0x108/0x1c0 ? pfxdosymlinkat+0x10/0x10 ? strncpyfromuser+0xaa/0x160 x64syssymlinkat+0xb9/0xf0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in smb3preauthhashrsp
ksmbdusersessionput should be called under smb3preauthhashrsp(). It will avoid freeing session before calling smb3preauthhashrsp().
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlegacy: Clear stale interrupts before resuming device
iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.
Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.
Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965macstart enter [ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965sethwready hardware ready [ 12.052324] ieee80211 phy0: ilapminit Init card's basic functions [ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: il4965up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965macstart Start UP work done. [ 12.058757] ieee80211 phy0: il4965down iwl4965 is going down [ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout [ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort [ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared [ 12.058819] ieee80211 phy0: ilapmstop Stop card, put in low power state [ 12.058827] ieee80211 phy0: ilapmstopmaster stop master [ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async asyncrunentryfn [ 16.132469] RIP: 0010:ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix the missing xastore error check
xastore() can fail, it return xaerr(-EINVAL) if the entry cannot be stored in an XArray, or xaerr(-ENOMEM) if memory allocation failed, so check error for xastore() to fix it.
iio: adc: ad7124: fix division by zero in ad7124setchannelodr()
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove()
Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove():
[ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] vfsremovexattr+0x92/0xc0 [ 57.339182] vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...]
Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM.
In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: 1st: in ocfs2xacleanupvaluetruncate(); 2nd: returning back to ocfs2xaremove() instead of going to 'out'.
Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.
filemap: Fix bounds checking in filemapread()
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: fix potential out of bounds in ucsiccgupdatesetnewcamcmd()
The "cmd" variable can be controlled by the user via debugfs. That means "newcam" can be as high as 255 while the size of the uc->updated[] array is UCSIMAXALTMODES (30).
The call tree is: ucsicmd() // val comes from simpleattrwritexsigned() -> ucsisendcommand() -> ucsisendcommandcommon() -> ucsiruncommand() // calls ucsi->ops->synccontrol() -> ucsiccgsynccontrol()
bpf: Fix out-of-bounds write in triegetnextkey()
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans
During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.
drm/amdgpu: add missing size check in amdgpudebugfsgprwaveread()
In the Linux kernel, the following vulnerability has been resolved:
signal: restore the overriderlimit logic
Prior to commit d64696905554 ("Reimplement RLIMITSIGPENDING on top of ucounts") UCOUNTRLIMITSIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if overriderlimit is set. This behavior change caused production issues.
For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueuealloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications.
Fix this by passing overriderlimit into incrlimitgetucounts() and skip the comparison to max there if overriderlimit is set. This effectively restores the old behavior.
ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize()
bpf: devmap: provide rxq after redirect
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: prevent the risk of a division by zero
As reported by Coverity, the logic at tpgprecalculateline() blindly rescales the buffer even when scaledwitdh is equal to zero. If this ever happens, this will cause a division by zero.
Instead, add a WARNONONCE() to trigger such cases and return without doing any precalculation.